Languguage OS 2/Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO/language/asa/notes

Text File | 1994-10-23 | 14KB | 400 lines

$Id: NOTES,v 4.2 1994/10/23 23:35:07 ingber Exp ingber $

========================================================================
            CONTENTS (Search on these words.)

@@FORTRAN
@@OPTIONS FOR LARGE SPACES
@@SPECIAL COMPILATIONS
@@PC CODE FOR TIME MODULES
@@HP CODE FOR TIME MODULES
@@EXAMPLES OF TUNING FOR SOME SYSTEMS
@@RANDOM SEEDS
@@CLARIFICATION OF GNU LICENSE

========================================================================
========================================================================
@@FORTRAN

20 May 93

Some users have requested a FORTRAN version of ASA.  I wrote early
versions of VFSR in RATFOR and used ratfor to translate to FORTRAN,
but picked C for my own convenience for these later versions.

There are at least two reasonable options for people using FORTRAN:

(1) If the FORTRAN code you use is relatively small compared to
the ASA code, you might try f2c to change your FORTRAN source
into C.  This code can be gotten from Netlib, by logging into
[e-mail] as netlib and then cd f2c.

(2) You can use CFORTRAN, available via anonymous ftp from
zebra.desy.de to interface your FORTRAN and C source and/or binary
codes.  It seems the easiest way to use this would be to call a FORTRAN
cost function from within the ASA C cost_function().

(3) You can see if your compiler will accept a rather simple approach
to calling your FORTRAN fcost() from the ASA C cost_function(), just
passing only those variables to fcost() necessary for your
calculation.  The procedure below worked on a Sun SPARC-2/4.1.3 using
gcc and Sun's f77.

(a) For example, in the user.c file, use "#if 0" to bypass the test
cost_function(), substituting your own, and of course properly
initializing the rest of the program using the templates provided in
user.c:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
{
#if HAVE_ANSI
  extern void fcost_ (double *q, double *x);    /* note "_" on fcost_ */
#else
  extern void fcost_ ();
#endif
  double q;                     /* returned by fcost_() */
  fcost_ (&q, x);
  *cost_flag = TRUE;            /* or, add some feedback from fcost_() */
  return (q);
#if 0
#if ASA_TEST                    /* ASA test problem */
...
#endif /* ASA_TEST */
#endif
}
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The requirement to use an "_" on the C-function call is machine
dependent.

(b) Create a file, e.g., cost.f, containing your FORTRAN cost
function, e.g., if the *parameter_dimension is 4, then:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      subroutine fcost (q_n, x)
      double precision q_n, x(4)
      ...
      q_n = ...
      end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Note that element x[0] in C is mapped to x(1) in FORTRAN.

(c) In the Makefile add to the "compile: " (tabbed) commands:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
compile: $(USEROBJS) $(ASAOBJS)
        f77 -c cost.f -lm
        @$(CC) $(LDFLAGS) -o asa_run $(USEROBJS) $(ASAOBJS) cost.o -lm
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Some compilers may require the addition of additional libraries and
options, e.g., -f77 on the CC line.  In general, it seems that the
proper compiler to link all the object files, e.g., cc or f77, should
correspond to the language of main().

========================================================================
========================================================================
@@OPTIONS FOR LARGE SPACES

5 Oct 94

For very large parameter-space dimensions, the following guide is
useful if you desire to speed up the search:

        Pre-Compile Options
add -DUSER_REANNEAL_FUNCTION=TRUE to DEFINE_OPTIONS
add -DUSER_COST_SCHEDULE=TRUE to DEFINE_OPTIONS
add -DASA_PRINT_INTERMED=FALSE to DEFINE_OPTIONS
SMALL_FLOAT may have to be decreased

        Program Options
set CURVATURE_0 to TRUE
set QUENCH_PARAMETERS to TRUE [a risk that negates proper sampling]
set QUENCH_COST to TRUE
set ACTIVATE_REANNEAL to FALSE
decrease TEMPERATURE_RATIO_SCALE
decrease COST_PARAMETER_SCALE
increase MAXIMUM_COST_REPEAT
decrease TESTING_FREQUENCY_MODULUS

        run time
use `nice -19 asa_run ...` as runs can be time- and CPU-intensive

If the parameter space dimension, D, is huge, e.g., 256x256=65536,
then the exponential of the generating or acceptance index to the 1/D
power hardly changes over even a few million cycles.  True annealing in
such huge spaces can become prohibitively slow as the temperatures will
hardly be diminished over these cycles.  This "curse of dimensionality"
will face any algorithm seeking to explore an unknown space.  Then,
the QUENCH_PARAMETERS and QUENCH_COST Program Options should be tried.

However, note that slowing down annealing sometimes can speed up the
search by avoiding spending too much time in some local optimal
regions.

========================================================================
========================================================================
@@SPECIAL COMPILATIONS

17 Dec 93

On an Intel Paragon Supercomputer, Graham Campbell
<[e-mail]> reports that the ASA test problem runs
without error or warning using gcc-2.4.5 as gcc -g -Wall.  However,
when using cc -O or gcc -g -O, compilation fails.

========================================================================
29 Mar 93

A problem in compilation,
} Though I compiled successfully
}
} on an old SUN 4/260 and a new IBM risc 6000 using both ansi c and
}
} old version c, troubles comes in when I try it on a newly obtained
}
} HWSs310 sparc workstation (claimed to be equivalent to sparc 10).
}
} When using cc compiler, both user.c and asa.c have been compiled,
}
} and it gave error message:
}
} undefined symbol  -dlopen
}                   _dlclose
}                   _dlsym
}
was solved by Walter Roberson <[e-mail]> by linking
with -ldl.
========================================================================
15 Jan 93

Davyd Norris <[e-mail]> reports that compilation
was successful on a Pyramid:
"On Pyramid OSx the -Xa compiler option had to be added so that the
compiler knows to expect ANSI code.  Also on our system there is no
stdlib.h include file."

========================================================================
========================================================================
@@PC CODE FOR TIME MODULES

4 May 94

From [e-mail] Wed May  4 11:19:58 1994
From: "Selverian, John" <[e-mail]>
To: "Ingber, Lester" <[e-mail]>
Subject: time calculation
Date: Wed, 04 May 94 14:19:00 PDT

Lester,

I move my code (along with ASA) back and forth between a PC & a UNIX
machine.  The time commands work fine on the UNIX machine but not on
the PC.  I currently use the ansi <time.h> header file and the
following command to get the time

#include <time.h>
...
main()
{
      double  start_time,end_time,elapsed_time;
      time_t    tloc;
...
      start_time = (double)time(&tloc);     /* define starting time */
      asa_main(....);                       /* call ASA */
      end_time = (double)time(&tloc);       /* define ending time */
      elapsed_time = end_time - start_time; /* define time spend in ASA */
...
}

This works on both machines & I would guess with all ansi-C compliers.

JS

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
14 Apr 94
Note that there now is only one set of time routines in asa.c, and that
now both asa.c and user.c pass two arguments to print_time(char
*message, FILE * ptr_asa_out).

========================================================================
18 Aug 93

For Turbo C, [e-mail] suggests adding another
include file, tcdefs.h, after
#include <stdlib.h>
in asa.h and in user.h.
/***** tcdefs.h */
/* Custom defines for Turbo C 2.0 and above */
#include <float.h>
#define MAX_DOUBLE    DBL_MAX
#define MIN_DOUBLE    DBL_MIN
#define EPS_DOUBLE    DBL_EPSILON
}
/*****/

He also suggests:
} When compiling for Turbo/MS C, you need to set INT_ALLOC=TRUE and
} INT_LONG=TRUE.  Lotsa warnings about unused variables, but no errors
} or warnings that might mean something more serious.

========================================================================
27 Aug 93

From [e-mail] Thu Aug 26 19:50:31 1993
Return-Path: <[e-mail]>
Date: Thu, 26 Aug 93 21:53:02 CDT
From: "zening  ge" <[e-mail]>
Subject: asa on PC

I have had the version 1.4 asa codes compiled using Turbo C++ 3.0 on my
386SX25 PC. The only thing needs to be changed is to set IO_PROTOTYPE
to FALSE.

It is necessary to turn IO_PROTOTYPES to FALSE to avoid the errors of
type mismatch in redefining "fprintf", "fflush", etc. For your example
problem, it took about 5 minutes to complete the computation on my
386SX25 PC without math-coprocessor.

========================================================================
31 Aug 93

Return-Path: <[e-mail]>
From: "Selverian, John" <[e-mail]>
To: "'Ingber, Lester'" <[e-mail]>
Date: Tue, 31 Aug 93 13:58:00 PDT

thanks for the tip.

Setting INT_ALLOC = TRUE and INT_LONG = TRUE solved the problem. Now
the PC and SGI give the same answers.

Just for your info I am running a 486 66Mhz PC with a math co-processor
with MS Quick C for Windows version 1.0.

========================================================================
========================================================================
@@HP CODE FOR TIME MODULES

4 Nov 93

The changes recommended below for hpux have been implemented using the
TIME_STD DEFINE_OPTION.
________________________________________________________________________
13 Sep 93

Sonja Zwissler <[e-mail]> wrote:

I have published the new version of asa on the ftp-server:
hpux.ask.uni-karlsruhe.de, which also means a publication on
ftp.csc.liv.ac.uk, ftp.cae.wisc.edu, hpux.cict.fr and some non-official
mirror-sites.

========================================================================
========================================================================
@@EXAMPLES OF TUNING FOR SOME SYSTEMS

12 Feb 93

The "Colville" problem required some parameter tuning.  In this case,
I felt the default options gave starting cost-temperature rates too
high, so I changed this scale.  I selected the starting values at
the arbitrary points 0, added greater precision, and also permitted
the runs to go longer than the "standard" specifications.  Using the
ASA options given below, the actual set of optimal parameters is
found to machine precision.  ASA achieves the actual global minimum
(within machine precision).  I did not spend any extra time fine-tuning
options to increase ASA efficiency.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CC = gcc
        -g
        -O
        -Wall
        -DSMALL_FLOAT=1.0E-35
        -DLIMIT_ACCEPTANCES=50000
        -DTEMPERATURE_ANNEAL_SCALE=1000
        -DCOST_PARAMETER_SCALE=1.0E-1
        -DUSER_INITIAL_PARAMETERS=TRUE
        -DACCEPTED_TO_GENERATED_RATIO=1.0E-4

parameter_dimension = 4;

for (n = 0; n < 4; ++n) {
    parameter_lower_bound[n] = -10.0;
    parameter_upper_bound[n] = 10.0;
    cost_parameters[n] = 0.0;
    parameter_int_real[n] = REAL_TYPE;
}

summ = 100.*(x[1]-(x[0]*x[0]))*(x[1]-(x[0]*x[0]))
    + (1.-x[0])*(1.-x[0])
    + 90.*(x[3]-(x[2]*x[2]))*(x[3]-(x[2]*x[2]))
    + (1.-x[2])*(1.-x[2])
    + 10.1*((x[1]-1.)*(x[1]-1.) + (x[3]-1.)*(x[3]-1.))
    + 19.8*(x[1]-1.)*(x[3]-1.);

return (summ);
________________________________________________________________________
RESULTS

best_generated_state=23.69555     number_accepted=120 number_generated=232
best_generated_state=0.2942304    number_accepted=429 number_generated=2496
best_generated_state=0.0005834838 number_accepted=733 number_generated=6229
best_generated_state=7.848137e-05 number_accepted=3185 number_generated=44762
best_generated_state=6.384848e-15 number_accepted=19968 number_generated=604224
[Here, all the best parameters were 1 to printout precision, %12.7g.]
best_generated_state=7.750362e-23 number_accepted=30510 number_generated=1767254
[About here some current_parameter_temperature's became the order of
SMALL_FLOAT.  Resetting SMALL_FLOAT would produce much more efficient
calculations at and after this point, assuming machine precision is
still meaningful.]
best_generated_state=3.736047e-24 number_accepted=33046 number_generated=2194731

========================================================================
========================================================================
@@RANDOM SEEDS

Date: Fri, 30 Sep 94 11:04:44 +0100
From: [e-mail] (Helmut Jarausch)

When calling asa_main(), the random generator always starts with the
same seed. I have introduced the tiny routine asa_seed
________________________________________________________________________
static LONG_INT seed = 696969;
double random_array[SHUFFLE]; /* random variables */

#if HAVE_ANSI
LONG_INT asa_seed(LONG_INT s)
{
#else
asa_seed(s)
{ LONG_INT s;
#endif
  if ( s > 0 ) seed= s;
  return seed;
}
________________________________________________________________________
which I can call prior to asa_main() to set the seed.

========================================================================
========================================================================
@@CLARIFICATION OF GNU LICENSE

19 Dec 92

Some added clarification of the GNU license:

Date: Sat, 19 Dec 92 14:07:45 PST
From: david d `zoo' zuhn <[e-mail]>
Organization: Cygnus Support -- [phone]

The LGPL says that if you use an LGPL covered library in your program, you
must do two things:

1) Provide the source code for the version of the library that you used,
   including any local changes that you have made.

2) Provide a means for the user to compile a new version of the library and
   re-link that with the initial application, to get the benefits of
   changing the LGPL covered source.  This is easiest done via shared
   libraries, but shipping .o files is acceptable.

========================================================================
========================================================================